
Patents Office 
Government Buildings 
Hebron Road 
Kilkenny 



I HEREBY CERTIFY that annexed hereto is a true copy of 
documents filed in connection with the following patent 
application: 



Application No. S980713 
Date of filing 31 August 1998 

Applicant TELLABS RESEARCH LIMITED, An 

Irish Company of Shannon Industrial 
Estate, Shannon, County Clare, Ireland. 



CERTIFIED COPY OF 
PRIORITY DOCUMENT 



Dated this /L day of June 2000. 




Ariiffieertuthorised by the 

Controller of Patents, Designs and Trademarks. 



• form mo*, i ......... . . . .. " ..* . ;/ >v , / - :•■ 

REQUEST FOR THE GRANT OF A PATENT 

PATENTS ACT, 1992 

The Applicant(s) named herein hereby reqiiest(s) 

_____ the grant of a patent under Part II of the Act 

^ lhc B r ^nt of a shori-term patent under Pari ill of ihe Act 

on the basis of the information furnished hereunder 

1- Applicant(s) 
Name 

TELLABS RESEARCH LIMITED 
Address 

Shannon Industrial Estate 

Shannon 

County Clare 

Ireland 

Description/Nationality 

An Irish Company 

2. Title of Invention 

"A Telecommunications System Controller Framework" 

3 * Declaration of Priority on basis of p revio usly filed anp l icationfsV for s*m* 
invention (Sections 25 & 26) . . . . ' ; . ; 



Previous filing date Country in or for 

which filed 

17/06/1998 . Ireland 

4 - Identification of Inventorfs) 
. Name(s).6f perso.n(s) believed 
• by Applicants(s) to be the inventorf s) 

Gerard Hartnett 

Address 

c/o Tellabsr Research Limited 

Shannon Industrial Estate 

Shannon, 

County Clare 

Limerick 



Filing No. 
980474 



Statement of right to he granted a na tent tSert mn 1 7(2) (b) ' r . : 
By .virtue of an Assignment dated May I. 1998 

Henis accompanying ihi s Request - tick as ap pmpimi.^ 

0) — X_. prescribed tiling fee (£50.00) 
<").. — X_ specification cpntaining.a description and claims 
: specification containing a description only 

• x Drawings referred to in. description or claims 
(iii) X An abstract 

(lV) Copy of previous application (s) whose priority is claimed 

(v) • ' ' Translation of previous application whose priority is claimed : 

(vi) _J<_ Authorisation of Agent (this may be given at 8 below if this 

Request is signed by the Applicant (s) 

Divisional Application (s> 

The following information is applicable to the present application which is made 
under Section 24 - 



Earlier Application No: 
. Filing Date: 



Agent 

The following is authorised to act as agent in all proceedings connected with the 
obtaining of a patent to which this request relates and in relation to any patent 
granted - 

Name . Address . 

John A: O'Brien & Associates The address recorded for the time being in 

the Register of Patent Agents, and currently 
Third Floor, Duncairn House, 14 Carysfort 
Avenue, Blackrock, Co. Dublin, Ireland: 

Address for Service/if different from that at 8^ ..... 
As above 



S '" ned , <v ^2l_ John A. O'Brien & Associates 

Date August 31. 1998 



"A Telecommunications .Sy stem Controller Framework" 

The invention relates to a telecommunications system controller framework. 

Heretofore, the approach for telecommunications system, controllers has been to link 
the software -very closely with the hardware resources and provide much dedicated 
functionjility.' this approach can provide a fast response time for real time 
telecommunications control, however, it lacks flexibility and modifications are 
difficult to make. 

Therefore, one object of the invention is to provide a framework which operates 
efficiently in real time, . and which may be easily modified to cater for changing 
telecommunications resources and volume requirements. 

According to the invention, there is provided a telecommunications system controller 
frarnework comprising:- 

application domain base objects in a base level; and 
meta data for the base objects in a meta level. 

Preferably, the meta data comprises meta objects, and there is preferably one meta 
object associated with each base object class! For example, there may be a base 
object associated with each slot in a telecommunications exchange rack, and one 
meta object associated with the slot class. 

Preferably, the rheta level operates in reaction to the base objects. Thus, the base 
objects perform the application processing and either make requests to the meta 
objects or transfer certain information to the meta objects so that they can react. 
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In one .embodiment the meta data includes base object containment information. 
Preferably, the meta data comprises means for using the containment information for 
interrogating the base object containment hierarchy to locate, a required object, in 
response to a request from a requesting base object. By storing the containment 
5 information, the meta level can interrogate the base level to locate required objects. 

In one embodiment/ the meta data includes persistence data. This allows the base 
objects to - be free from the need to perform any data persistence operations, thus 
helping to provide a fast response time, and also consistency in the manner in which 
10 persistence data is dealt with. - 

In one embodiment, the meta objects comprise means for performing persistence 
data operations transparently to the base objects. 
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In another embodiment, the meta data includes real resource information for 
attributes of the base objects. Preferably, the meta objects comprise means: for 
verifying base object proposals to update real resource attributes, arid for performing 
the updates if approved. In one embodiment, the meta data objects comprise means 
for publishing real resource update events on a channel. The base objects are 
divorced frdm the real resources, thus allowing flexibility as the base objects may be 
modified to cater for different functionality without the need to deal with the manner 
in which they interface with the real resources. Location on a channel is an effective 
way of disseminating real resource update information. 

25 In one embodiment, the meta data includes condition and alarm information. 

Preferably, the meta objects include controller backup information and means for 
updating a backup controller. 



The invention , will be more clearly understood, from the following description of 
some embodiments thereof, given by way of example only with reference to the 
accompanying drawings in which:- 

Frg. 1 is a diagrammatic representation of a framework; and 

Figs. 2 to i5 inclusive are diagrams indicating interaction of layers in the. 
framework.' 

Referring now to Fig. 1, a framework 1 for a telecommunications system controller is 
illustrated. In this embodiment, the telecommunications system is for handling 
ATM cells. The framework 1 comprises an application domain base level 2 having 
base objects 3. If also comprises, a meta level 4 comprising meta objects 5. In the 
example illustrated, the base objects 3 are for telecommunications system card slots. 
This is a class of base object and there is one meta object 5 for each class. 

Briefly, the base objects 3 transmit various requests- and signal actions to the relevant 
meta object 5:. The meta object. 5 accesses the database 6 and carries out various 
actions relating to base object containmerit, persistence data, real resource update, 
and controller backup updating. The meta level 4 interfaces with real resources 10: . ... 

Referring now to Fig. 2, a general scenario illustrating operation of the framework 1 
is illustrated. In this illustration, a slot object 3 accesses a corresponding meta object 
5, which in turn accesses a resource attribute adapter 11, In general, the base level 
defines the application logic, while the meta level performs various actions which 
can be more efficiently performed by the meta objects. The meta lever describes a 
number of different aspects of the base level .software including containment 
information, information on which attributes are persistently stored, real resource 
information, and backup information. 
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Thus, complex processes such as ' downloading all. of the information in an object 

hardware can be performed by the meta level 4. 

Referring to Fig. 3, an example is illustrated whereby, an attribute is set using a base 
level function. Application code calls a setLineCoding method on a SlotDo base 
object 3. This informs the meta level, calling the setFourBaseLevel function on the 
meta attribute, the meta attribute verifies the new value can indeed be changed 
from its point of view. If, for example, the attribute was representing a value on the 
line card, the real resource aspect of the meta object would have provided a 
verification strategy object to the meta attribute. In this case the verification strategy 



^ object would try setting the attribute on the line card. 



Referring now to Fig, 4, an example is illustrated whereby a parent object creates a 
contained object. When doing this, it informs the meta level of the new object using 
15 notifyCreate. There are three phases as foUows:- 

(a) construction, in which the object is allocated, 

(b) initialisation, in which it is fully set up, and 

(c) notification, in which the meta object is notified. • • 
These three phases are controlled hy the parent object. 
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As stated above, there is one meta object per class of domain object. Meta objects 
are containers for other objects which describe the domain object class and contain 
attributes, actions, an other information such as containment and persistence 
information. The meta objects also contain event channels which are informed when 
various events take place. For example, subscribers can learn of instance creation 



and deletion using these channels. In the example ofF lg: 3, a persistence object acts 
as a subscriber receiving-notifications of instance creations. 

In-more detail, the base objects represent the problem domain and include card, slot 
and ATM interface objects. They are implemented as standard C++ objects and 
have get/set methods for attributes. The method may use methods on other base 
objects and they may create their contained objects and may contain state, state 
machines and support alarm conditions. The base objects invoke services on the 
meta level. In an example described, above, where an attribute is being, set on the 
base level the base level invokes a method on the meta level informing it of attribute, 
value changes. 

The attributes are contained in the meta objects 5. Attributes can be get/set from the 
meta. level as well as .from the base level. This is used when attribute values are 
coming from the meta level as well as frpm the base, level, such as from persistent 
storage/ Referring to Fig, 5, a mechanism for getting and setting. attributes is 
described, The attribute calls the base level ; functions for setting and getting the 
value. 

Meta attributes are declared using a hierarchy of abstract classes to avoid including 
much code in header files. Referring to Fig. 6, a mechanism for getting an attribute 
from the meta level is illustrated. 

Meta actions support the domain concept of actions in the domain object: They are 
informed when, the base level is running an "action". They can also run the action :. 
from the meta level. . : - 

Keys are simple classes which represent the information needed to uniquely identify 
an instance of a class. Keys are made of inheritance chains. If an object of the class 
can be contained in objects of another class then the set of that class will inherit from 
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its container's key class. In this example, Slot js contained- in Shelf. Keys can be 
used to find an instance of a base object. This behaviour is supported from the mera 
level containment information, as illustrated in Fig. 7. The opposite scenario can 
also happen, namely an instance can set a key value. To do this the instance sets the 
part of the key it understands. It needs its parent object to set the rest of the key., and 
so on up the tree. 

The containment information of the meta level provides the following functionality: 

- finding a domain object using a stream representation of its identity. 

- creating a new domain object identified by a string representation of its 
identity. .'. 

15 " creating an iterator for instances of the domain class. 

- finding an object based on a key representation of its identity: 

The "contain info" needs to know information such as the string representation of 
20 the class name, and this is obtained from the rheta object. It also needs the 
containment information from its container classes to perform some of its 
functionality. Accordingly, instances of containment information objects tend to be 
changed together in a way that reflects the containment tree. 

25 There are a number of different concrete containment information classes which 
implement the generic behaviour specified by the abstract ContainlnfoFor. These 
are: 

- SingleParentcontainlnfoFor - a contain info for a class of objects which is 
30 directly contained by a singleton. The objects are not unique within their 



container and . so need , an identifier to specify them uniquely within a 

container. 



UniqueContaihlnfoFor - a contain info for a class of objects which a 
unique within their container (e.g. there can be only one Card in a Slot). 
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- ChildContainlnfoFor - stores containment meta-level information for 
objects which can be contained in other objects. The objects are not 
unique, within their container and so need an identifier to specify them 
uniquely within a container. 

Referring to Fig. 9, an example problem domain is illustrated in which there is a 
singleton representing the whole system, shelves are contained, in the system, slots 
and fans are contained in a shelf and cards are uniquely contained in a slot. 

Referring to Fig. 10, ChainedContainlnfo classes for the above problem domain 
containment tree are illustrated/ The . ShelfMeta contains the 
SingjeParentCpntainlnfoFor. It also contains ContaihlnfoAdapers for its two types 
of contained objects. 

The meta level classes for containment need to use Facilities implemented by the base 
level. These facilities are defined in the following two abstract classes :- 

- CoritaiherOf - specifies the class : is a container of another type of object. 
Means findObject, findFirstObject and .findNextObject, all taking an 
identifier, must be implemented: 

- ContainerOfUnique - specifies the class is a container of a unique object. 
Means findObject taking no identifier must be implemented. 



Referring to Fig. 1.1, the class declarations for the domain objects Shelf and Slot 
illustrated. 



Some of the attributes of the base objects need to be persistently stored and this is 
handled by a meta object. The meta object contains an "AbstractPersistObject" 
adapter in the same way. The AbstractPersistObject provides interfaces whereby it 
can load all objects of a class from persistence and can subscribe to object creations 
and deletions, h also contains AbstractPersistAftr objects which are created for each 
attribute which is.persistent. 

There are two different concrete types of AbstractPersistObject. The 
PersistStaticObjectAdapterFor is for domain objects which are expected to exist 
before the loadObjectsFromPsl function is called. There are a fixed number of them 
in the system and they merely need to be initialised. 

The loadObjectFromPsl goes through each entry in the persistence storage layer, 
finds the existing object that refers to the entry, then uses the AbstractPersistAftr , 
objects to extract the information from the raw persistence storage and set the 
appropriate attributes. 

The other concrete AbstractPersistObject is the PersistDymanicObjectAdapterFor. 
This concrete class is used where the instances'are not. expected to pre-exist before 
the loadObjectsFromPsl call and the persist adapter will need to cause them to be 
created. The container of the object will do the actual creating and as such will, need 
to implement the makeObject function. 

Referring to Fig. 12, the declarations for setting an attribute are illustrated. The 
AbstractPersistAftr subscribes to changes in the meta attribute and persistently Stores 
the new values when changes do happen. The mechanism for loading an object from 
persistence storage is illustrated in Fig. 13. 



In the example illustrated, the contain info is passed to the whole stream. It finds the 
container and calls ma.keObject on. If the whole operation is successful a new object. 
• is returned. This is then initialised using the storage from the persistence layer. 
Finally, the notifyCreate is called on the meta level. 

Three phases of construction used to form the persistence layer are shown in Fig: 14 . 
The PersistDymanicObjectAdapterFor uses the makeObject to create the object. It 
uses setObjectFromStorage to initialise it. It then informs the meta level using the 
notifyCreate. 

The meta level is also used for tracking and updating real resources. Typically, there, 
are proxy objects for interacting with objects on the real resource, there are two 



scenarios: 



(a) When the attribute is set the real resource must try to set. the value first, 
this results in communicating with a middleware proxy. If this works, 
the rest of the process of setting an attribute is run. 

(b) If the real resource needs to be configured from the controller, all of the 
real resource attributes need to be downloaded to the hardware. An 
action means calling a proxy function on the real resource. . The proxy 
function can be called and return-checked in the base object function. If 
an attribute is read-only on the hardware and it can change autonomously, 
the Getfunction in the domain object can call the proxy directly to get the 
value from the hardware. 



A mechanism for setting an attribute on a real resource is illustrated in Fig. 15. 
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The meta level also provides an agent interface to the base objects for the agent sub- 
system. Some attributes may not be visible on the agent interface or they may be 
more restricted in their scope i.e. read-only instead of read/ write. 

Two other aspects of base objects and their representation as meta objects , are 
polymorphism and text interfaces. Polymorphism is where there is a base class 
domain object from which derived classed are to be inherited. The derived classes 
want to add new attributes and. actions and so will have extra meta information as 
well as the information from the base class. 

The text interface provides facilities for representing objects and attributes as text 
strings. It is used by the CLI software. 

The meta-level architecture may also support domain object versioning. 

It will appreciated that the invention allows application: code and logic to be 
independent of application level services. This means that changes to horizontal 
application services can be made without affecting the general application logic, 
avoiding sweeping changes to the software system. These advantages have been 
achieved with very simple and well defined interfaces between the base and the meta 
level.' ' 



New functionality can be added to the system without affecting the application code 
because must of the persistence, real resource interface, text interface, and auditing 
functionality is written in terms of the meta level. 

The invention also achieves a high level of reuse, and qualification of the system is 
simplified. 
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The invention is not limited to the . embodiments described, but may varied in 
construction and detail within the scope of the claims. 
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Claims 



1. 
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A telecommunications system controller framework comprising:- 
applicarion domairi base objects in a base level; and 
meta data for the base objects in a meta level. 

A framework as claimed in claim i; wherein the meta data comprises meta 
objects, and wherein there is one meta object associated with each base object 
class, and wherein the meta level operates in reaction to the base objects and, 
wherein the meta data includes base object containment ^formation, and 
wherein the meta data comprises means for using the containment 
information for interrogating the base object containment hierarchy to locate 
a required object in response to a request from a requesting base object. 

A framework as claimed in claims 1 or 2, wherein the meta data includes 
persistence data, and wherein the meta objects comprise means for 
performing persistence data operations transparently to the base objects, and 
wherein the meta data includes real resource information for attributes of the 
base objects, and wherein the meta objects comprise means for verifying base 
object proposals to update real resource attributes,, and for performing the 
25 updates if approved, and wherein the meta data objects comprise means for 

publishing real resource update events On a channel. 
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A framework as claimed in any preceding claim, wherein the meta data 
includes condition and alarm information, and wherein the meta objects 
include controller backup information and means for updating a backup 



controller. 



A framework substantially as described with reference to the drawings 
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